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DRM: Update since our talk @ XDC2012 
Drivers: Per-process virtual address space 


e Intel: WIP; Nouveau & Radeon: done 


X-Server 
e DRI3: Use DMA-Buf instead of GEM flink for BO-passing 
e but the X protocol is still unsecure by design... 


Wayland/Weston 
e Designed with security in mind from the ground up 
e now uses DMA-Buf instead of GEM-flink to provide client isolation 


e relies on DRM drivers for its security 
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But How to Build a Secure OS? 


Some critical concepts 


Complete Mediation Requires client isolation in the HW, kernel, the 
display server and sandboxing 


Least Privilege Need for mandatory security within user sessions 
and means to identify privileged clients 


Trusted Path Unspoofable ways for user and trusted apps to 
communicate; Allows reading the user’s intent 


All of the above needed to prevent evil apps from hurting you! 
[Saltzer and Schroeder, 1975, Loscocco et al., 1998] 
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Challenges of creating a secure Desktop 1/2 


Some common GUI requirements are un-secure by design 


e Clipboard monitoring 


e Acceptable: check that data can be pasted (for GUI toolkits) 
e Unacceptable: access sensitive data 


e Key events monitoring 


e Acceptable: global hotkeys 
e Unacceptable: keylogging, reading your passwords 


e Input-injection 
e Acceptable: visual keyboards / accessibility 
e Unacceptable: command injection 
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Challenges of creating a secure Desktop 2/2 


e Focus raising 


e Acceptable: show apps requiring user input before a power down 
e Unacceptable: window stealing the user’s input while authenticating 


e Full-screen support 


e Acceptable: video, gaming, full-screen shell 
e Unacceptable: spoofing the greeter 


Solutions by the X-Server vs Wayland/Weston 


e X-Server: One valid use case — access granted to everyone 
e Wayland: One invalid use case — access denied to everyone 
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Current solution on Wayland/Weston 


Wayland’s privileged interfaces: 


Not defined yet, many discussions 

partially due to the security implications 

e the compositor sometimes need the user intent (Trusted Path) 
e users or packagers may want to work around that! 


Example: Wayland/Clipboard 


Reading the clipboard doesn’t seem to be defined. Drag & Drop is 
however supported because the compositor gets the user’s intent! 
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Example of policies for accessing a privileged iface 


Allow Deny Allow hard- 
everything everything coded Apps 
O @ O Q Q O 
App. A X-DE App. B X-DE App. C 


App App 
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Challenges of defining policies 


Challenges of defining policies 


e Many Desktop Environments (Gnome, KDE, Tizen, XFCE, etc...) 
e DEs won't agree on a single policy 

e Cross-DE apps cannot ship with a policy for every DE 

e Packagers need a simple policy interface 


Possible solution? 


e Abstract the decision process in a multi-backend library 
e Create a generic policy and per-DE tweaks 


9/47 


a mupuf.org 


Outline 


Current Security of the Graphic Stack 
Introducing Wayland Security Modules 

Facts and myths about humans and security 
Security Uls, Infrastructure and Pitfalls to Avoid 


Conclusion 


10/47 


gP mupuf.org 


Wayland Security Modules 


Goals 


e Provide security decisions for Wayland privileged ifaces 
e Help DEs store policy for their ifaces in a centralised way 
e Support innovation and standardisation over time 


How we do that 


e Hooks on all privileged ifaces in the Wayland API 

e Support for any backend/module: just a few symbols to export 
e Simple: currently about 1100 LOCs w/ default backend 

e Very extensible! 
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Example of policies for accessing a privileged iface 


| LibWSM | 
Allow 
everything get_p get_p 
Comp. B | Comp. C| 
@ G @ O O 
App. A X-DE App. B X-DE App. C 


App App 
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How to Use 


Modifications to a compositor 


@ wsm_init( on compositor start 

@ wsm_new_client() on new client 

© Users choose a backend and write a policy — or use ours! 

© When implementing privileged ifaces, call wsm_get_permission() 
© Got custom semantics? Call wsm_get_custom_permission() 

© wsm_client_free() and wsm_fini() to clean up 


Source 
https://github.com/mupuf/libwsm 
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LibWSM Security Decisions 1/2 


Four default semantics 


Allow Client explicitly allowed use of a privileged iface. 


Soft Allow Client allowed, but there could be issues. We 
recommend notifying the user. 


Soft Deny Client denied, but no particular concern. You could 
grant access via trusted Uls or prompts. 


Deny Client explicitly denied by policy, don’t proceed. 


If LibWSM answers something else, implement Deny. 
If there is no policy, the default backend will reply Soft Deny. 
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LibWSM Security Decisions 2/2 


Why the distinction? 


Hard decisions represent the actual security policy. Please respect it. 


Soft decisions are assumptions about what's best. Compositors can 
probably do better than just allow/deny. 


Security notifications, Trusted Uls, User-driven access control and 
Permission prompts should come to mind with soft replies. 
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Extending LiobWSM is Easy! 


Support for custom capabilities... 
Compositors should be let to innovate securely: custom ifaces like 
_WESTON_FULLSCREEN can be mediated. 


Custom decision semantics... 


If you implement specific behaviours, you can express them in the 
policy e.g., “allow if no sensitive apps open” for WSM_SCREENSHARING. 


Different policies per compositor... 
Write per-DE policies just like in menu or autostart files, e.g.: 


[GNOME] 
WSM_RAISE_FOCUS=deny 
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LibWSM Capabilities 1/3 


WSM_SCREENSHOT 


Take a screenshot of the whole screen (Soft Deny) 


WSM_SCREENSHARING 


Record the screen continuously (Soft Deny) 


WSM_VIRTUAL_KEYBOARD 


Inject or filter input events on keyboard (Soft Deny) 


WSM_VIRTUAL_POINTING 


Modify the position of the pointer and simulate clicks (Soft Deny) 
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LiobWSM Capabilities 2/3 


WSM_FULLSCREEN 


Use the entire screen (Soft Allow) 


WSM_GLOBAL KEYBOARD SEQUENCE [obj: key sequence] 


Receive keyboard sequences even when not active (Soft Deny) 


WSM_FORWARD RESERVED KEYBOARD SEQUENCE [obj: key sequence] 


Receive reserved compositor sequences when active (Soft Deny) 


WSM_RAISE_FOCUS 


Raise the window and grab focus programmatically (Soft Allow) 
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LibWSM Capabilities 3/3 


WSM_CLIPBOARD_COPY 
Copy programmatically to the clipboard (Allow) 


WSM_CLIPBOARD_ PASTE 
Paste from the clipboard (Soft Deny) 


= Ofcourse this list is provisional. Please suggest corrections/additions 
at https: //github.com/mupuf/libwsm/issues. 
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The Default Backend 


Policy managed with files 
e default policy, app-specific policies, policy templates (WIP) 
e system-wide policies can be customised by users 

A single source of policy per app at any time 


e more manageable for packagers and distributions 
e better visibility (includes in SELinux are a recipe for trouble) 
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Example Default Policy 


Wayland Security Entry] 
Exec=* 
Version=1 


All Compositors] 
WSM_FULLSCREEN=soft-allow 
WSM_CLIPBOARD_COPY=allow 
WSM_RAISE_FOCUS=soft-allow 


Paranoid Shell] 
WSM_FULLSCREEN=deny 
WSM_CLIPBOARD_COPY=deny 


GNOME] 
_GNOME_USE_SHELL_API=basic-access 


Mupuf] 
WSM_FULLSCREEN=soft-allow 
_WESTON_FULLSCREEN=soft-allow 


Weston] 
_WESTON_FULLSCREEN=implicit-deny 


a mupuf. org 
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Example Policy for an Application 


(Wayland Security Entry] 
Exec=/usr/bin/example 
Version=1 


All Compositors] 
WSM_FULLSCREEN=allow 
WSM_CLIPBOARD_COPY=deny 


Paranoid Shell] 
WSM_FULLSCREEN=deny 
WSM_CLIPBOARD_COPY=deny 


GNOME] 
_GNOME_USE_SHELL_API=allow 


Mupuf] 
WSM_FULLSCREEN=allow 
_WESTON_FULLSCREEN=permanent~-allow-if-frequent 


[Weston] 
_WESTON_FULLSCREEN=allow 
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This is Just a Backbone 


We made it as flexible as possible. 


Goal: positive user experiences 
e Easy to conceptualise and edit policy, easy to add Ul 


e Soft decisions let DEs build their own UX 


Need something more for your shell? Talk to us! 
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Potential Security Tasks & Interactions 


GUls might be necessary for 


e Answering an app’s permission request 

e Installing an app which needs privileges 

e Knowing what privileges an app has 

e Revoking an app’s privileges 

e Prevent annoying apps from requesting privileges 
e (“why” may influence the design) 


This is the job of DEs! 
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Introducing my research group... 


I’m a PhD student at UCL Info Sec 
We specialise in usable and productive security. 
I’m investigating how Linux users manage their security! 


e We don’t know what makes security software work... yet 
e We don’t know how to change home user behaviour... yet 
e But we know how to do user research! 


Shameless advertising: http: //sec.cs.ucl.ac.uk 
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Some Research Knowledge 1/3 


User time is precious, respect it 


e Nobody wants to perform security tasks! People rationally reject 
costly security advice 


e Nobody has time for security! More security pressure decreases 
willingness to comply 

e Most security warnings discarded in 2s. One reason: people 
habituated to warnings, but there could be others 


[Beautement et al., 2008, Herley, 2009, Krol et al., 2012, Akhawe and Felt, 2013] 
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Some Research Knowledge 2/3 


Security is desirable 


e People in corporate want insecure options hidden by default 
e They still bypass or disable security to get stuff done 
e And still deploy their own security strategies to compensate 


[Bartsch and Sasse, 2013, Kirlappos et al., 2014] + private conversations with Sasse 
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Some Research Knowledge 3/3 


Home users are not very concerned 


e Home users think they will never be targeted. Telling them about 
opportunistic criminals best triggers concern 


e Speak of malware as medical infections, it’s better understood 
than other metaphors 


e Some people think antivirus software keeps them safe 
e Linux users feel Linux is more secure (but it’s not) 


[Camp, 2006, Wash, 2010, Krol et al., 2012] + market research and own observations 
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What Makes Security Work? 


Warning: nobody really knows! 


Some sanity principles for now: 


© Don't put the cost of security on users! 


e Interaction cost of security 
e Initial cost of ‘opt-in’ security 
e Lost features — hinders practices 


© Don't ask app devs to do the security 
© Complex policy = opaque breakdowns 
© Test with real people as often as possible 
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@ Trusted Uls 


What, How 


e Uls that are controlled by the OS/Compositor (not by apps) 
e Trusted path between Trusted Uls and user 
e Which means need for a Ul embedding protocol 


Goal 


e Indicate user intent without policy when interacted with 
e Trusted File Dialog / Power boxes [Yee, 2004] 
e Secure “Take Photo” button on Android [Roesner et al., 2012] 


e Some Trusted Uls in Windows 8 and OS X 
e Sadly, they require API changes in toolkits... 
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PoC: File Chooser Dialog 


Remediating the Need for Filename Autocompletion 


Name: l My file name ] 


Save in folder: < | @ steve | Development | gdbus-sfad | server [sre] Create Folder 


Places N Name v Size Modified 
Q Recent sandboxfilechooserdialog.c 67.0kB 12:06 
fi Home sandboxfilechooserdialog.h 17.5kB 12:04 
[im Desktop sandboxfilechooserdialogdbusobject.c 301.1kB 12:13 
Beori sandboxfilechooserdialogdbusobject.h 43.2kB 12:13 
sandboxfilechooserdialogdbuswrapper.c 43.2kB 12:08 
© Downloads sandboxfilechooserdialogdbuswrapper.h 743 bytes Yesterday at 20:02 
H movies sandboxfilechooserdialoginterface.xml 5.9 kB 12:09 
JÌ Music =| sandboxutilsclientmanager.c 14kB Yesterday at 14:20 
‘Ê Pictures | sandboxutilsclientmanager.h 967 bytes Tuesday 
@ wastebasket sandboxutilscommon.h 595 bytes 23:20 
Devices sandboxutilsd.c 2.0 kB Yesterday at 14:20 
Computer = sandboxutilsmarshals.c 4.6 kB Yesterday at 14:20 U 
Pi |= sandboxutilsmarshals.h 803 bytes Tuesday 
[i Courses All Text Files v 
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An Initial PoC for GTK+ File Chooser Dialog 


e Mirror the “normal” usage of API: almost all apps portable 


e Prevent attacks when user interacts w/ GUI 


e Expose statefulness and error handling to apps 
Configuration User Interaction Data Retrieval 


WY sfcd:: response 


DA 


7 


t sfcd_set_*() : sfcd_run() f 


| Microsoft switched to a full async programming model: no error 


| 
handling when permission is denied! 
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Is it really that simple? 


Issues arising with new FCD 


e File preview: should move to built-in DE routine 


e Custom widgets: needs a Ul embedding protocol 
would work for apps currently using such widgets 


e Autocompletion of file extension when saving? 


| Truth is both APIs and widgets need to be redesigned. 


i 
More complex workflows need entirely new Uls 
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Another Example: X11 Selections 


An actual security issue 


e Apps can paste selection content w/out mediation 
e They routinely check if they support the content type of selections 
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Is a Secure Clipboard Possible? 


Apps should receive clipboard events 


e Implication: need a reserved hotkey for pasting 
e And Trusted Uls buttons and menu items 
Paste | Import from Clipboard | 


e We do need a (two-way) UI embedding protocol 


Risk of issues down the road 


e What about apps that use other labels/keyboard sequences? 
e Share your concerns/critics with us, it will help! 
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@ Permission Requests 


Permission requests don’t provide security. 
Systematically ignored: lack of experience, 
disruptiveness, immediate gratification bias, 
economic rationality / compliance budget 


How to ask for Permission [Felt et al., 2012] 


Approval 
Does it need to 
work without 
immediate user 

approval? 


Yes Yes Yes Yes No Yes 
5 y 
Automatic Confirmation Install-time 
Trusted UI s : 
grant dialog warning 


Alterable 
Can the action 
be altered by 
the user? 


Initiation 
Did the user 
initiate the 
request? 


Revertibility Severity 
If abused, is it 
just an 


annoyance? 


undone with 
inimal effort?, 
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Permission Requests (are totally offtopic) 


You have 2 seconds per UI! No more! 


e Don’t expect rational decisions, rely on interaction cost instead 
e Make it useful and actionable 

e Identify who is asking for permission 

Visualise what is asked for 


[Reeder, 2011 on NEAT warnings, Day, 2014 on sandboxing] 


= Good design is DE-dependant. No infrastructure work needed in 
Wayland for permission Uls. 
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© Authentication Uls 


Spoofing Auth Uls is highly rewarding... and easy 


e Just fake the polkit UI! 

e Or go fullscreen and fake: 
e The whole desktop environment 
e The greeter/lock screen 
e A Web login page 


© Cyberoam 
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Please Pwn my Authentication Ul 


a mupuf.org 


Please Pwn my Authentication Ul 


When users open your rogue app’s settings, display this: 


Sys Configure 
+ 


a Authenticate x 


T System policy prevents 
P modifying the configuration 


An application is attempting to perform an action 
that requires privileges. Authentication as one of the 
users below is required to perform this action. 


(Ehan. (shaun) $ ] 


Password for shaun: { | 


Authenticate 


> Details 
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Defences 


Three (imperfect) approaches 


Unspoofability GFX effects only the shell can make 
Indirections add a user action to all auth (e.g., Windows UAC) 
Mutual Auth make the DE show the user a secret 


a All three can be broken with a bit of user inattention/confusion. 
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Attacking Auth UI Defences 


Unspoofable Effects 


e e.g., wobbly animation on background windows 
e Not trivial to simulate but... 
e Will users pay attention to the auth dialog or to the background? 


Indirections 


e Ctrl+Alt+Del? Bind each key individually and show your fake UI 
e Or tell the user an error occurred and pop a new Ul 


Actual out-of-band communication is necessary! 
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Example: "Anti-Phishing" Mutual Auth 


Login 


Click the pictures that correspond 
with your secret categories: 
(use arrows to scroll left and right) 


@ Reco) 


© Confident Technologies 


mVERY MUTUALAUTH 


| Tell users “The image server is down” and they all proceed! 


Lesson: cultural context matters. Errors expected on the Internet 
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Thanks for your Attention! 


What we have 


e ALibWSM prototype to enable privileged interfaces 
e Open problems for security Uls design 
e More detailled versions on mupuf . org/blog 


What comes next ag 
e Martin to finish and maintain LibWSM Sag DodierLazáio 


e Steve to study Linux users’ security s-dodier-lazaro@cs.ucl.ac.uk 
practices in-the-wild Martin Peres 


i ae martin.peres@labri.fr 
e All of us to review privileged APIs? ee 
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